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Abstract —Due to the presence of buffers in the inner network 
nodes, each congestion event leads to buffer queueing and thus 
to an increasing end-to-end delay. In the case of delay sensitive 
applications, a large delay might not be acceptable and a solution 
to properly manage congestion events while maintaining a low 
end-to-end delay is required. Delay-based congestion algorithms 
are a viable solution as they target to limit the experienced end-to- 
end delay. Unfortunately, they do not perform well when sharing 
the bandwidth with congestion control algorithms not regulated 
by delay constraints (e.g., loss-based algorithms). Our target is to 
fill this gap, proposing a novel congestion control algorithm for 
delay-constrained communication over best effort packet switched 
networks. The proposed algorithm is able to maintain a bounded 
queueing delay when competing with other delay-based flows, and 
avoid starvation when competing with loss-based flows. We adopt 
the well known price-based distributed mechanism as congestion 
control, but i) we introduce a novel non-linear mapping between 
the experienced delay and the price function, and ii) we combine 
both delay and loss information into a single price term based 
on packet interarrival measurements. We then provide a stability 
analysis for our novel algorithm and we show its performance 
in the simulation results carried out in the NS3 framework. 
Simulation results demonstrate that the proposed algorithm is 
able to: achieve good intra-protocol fairness properties, control 
efficiently the end-to-end delay, and finally, protect the flow from 
starvation when other flows cause the queuing delay to grow 
excessively. 

Keywords — Delay-sensitive communication, congestion control, 
network utility maximization. 

I. Introduction 

N OWADAYS, many Internet applications aim to work not 
only at maximizing their throughput, but also at meeting 
crucial delay constraints in the transmission of data flows. 
Video conferencing applications are a good example of such 
delay sensitive services, where an excessive playback delay 
with the audio/video stream can drastically affect the quality 
of an internet call. On-line video gaming and desktop remote 
control are other examples of applications that require low 
latency communications. When network links are congested 
these applications need to adjust their sending rate such that 
the experienced one-way delay is kept low and bounded, 
while preserving fairness with other flows. This reduces to 
a constrained resource allocation problem, which has to be 
solved in a fully distributed manner due to scalability issues. 

Congestion control algorithms can be seen as distributed 
methods to solve optimal network resource allocation prob¬ 
lems. These algorithms are usually categorized in primal or 
dual algorithms, based on the solving method adopted [ 1J— 
Q. From a more practical point of view, the primal and 


dual congestion control algorithms roughly correspond, though 
not exactly, to loss-based and delay-based algorithms. Loss- 
based controllers are widely deployed over the internet (e.g., 
TCP) and use congestion events triggered by packet losses 
to perform rate adaptation. However this class of controllers 
does not take into account any type of delay measurement, 
such as the One-Way Delay (OWD) or the Round Trip Time 
(RTT). Hence, there is no control on the latency that the 
packets might experience on their route and large delays 
can be experienced in the case of long buffers in the inner 
network nodes. On the other hand, delay-based congestion 
control algorithms can overcome the increasing delay issue by 
detecting congestion events from OWD measurements. Delay- 
based congestion control algorithms are therefore suitable for 
low delay applications since they are able to keep a low 
communication delay by adapting the sending rate to the 
evolution of the delay. However, they usually suffer from 
poor performance when sharing the network with loss-based 
controllers. Loss-based congestion control algorithms always 
fill the buffers of the inner network nodes before triggering 
congestion events. Therefore, any delay-based flow sharing the 
same bottleneck might experience a too large queuing delay 
and quickly reach starvation (i.e., a sending rate close to zero). 
There is the need for a congestion control that could enable 
low delay communication whenever possible (essential for low 
delay communication) and that is robust against the presence 
of loss-based flows (mostly deployed in the internet) 

Beyond this coexistence challenge, new congestion control 
algorithms to be deployed in the Internet need: i) to pro¬ 
vide good inter-protocol performance when competing against 
existing controllers, such as TCP; ii) to mainly act at the 
endpoints rather than at the inner network nodes (modifications 
of the inner network nodes are particularly difficult); in) to 
be robust to noisy measurement of network parameters (i.e., 
propagation delay). Many congestion control algorithms have 
actually been proposed in the past, but to the best of our 
knowledge there is no delay based congestion control algo¬ 
rithm able to well perform in the presence of loss-based flows 
and satisfying at the same time the three main implementation 
challenges listed above. 

In this work, we target to fill this gap by proposing a new 
distributed Delay-Constrained Congestion Control (DCCC) 
algorithm that is able to adapt the sending rate to both loss 
and delay-based congestion events and to overcome the afore¬ 
mentioned issues. The ultimate objective is to preserve the low 
end-to-end delay constraint that is imposed by the application, 
when competing with other delay-based controlled flows, and 
at the same time, avoid starvation when competing with loss- 
based flows. In more details, we consider a scenario where 
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Fig. 1. Network system model. 


users send delay-sensitive data over a packet switched network, 
as shown in Fig. [T] The network is composed of a set of links 
and nodes, with the links being shared among different users 
who set up unicast communications between two endpoints of 
the network. The proposed controller measures the experienced 
OWD and the interarrival time of the received packets at 
the receiver node, and adjusts the rate accordingly in order 
to maximize the overall utility of the network flows. The 
key intuition is that the interarrival time of the packets is 
correlated to both losses and queueing delay variations. Hence, 
by using this metric, the controller is able to work in both 
delay-based and loss-based environments. The ability to avoid 
starvation when competing against loss-based flows, and still 
guarantee a bounded experienced delay is made possible by the 
use of a non-linear mapping between the experienced OWD 
and the penalty congestion signal used by the rate update 
equation. The DCCC algorithm has been implemented in the 
NS 3 network simulator and has been tested under different 
topologies and working conditions. Simulation results show the 
ability of the proposed algorithm to keep bounded the value 
of the experienced OWD, to achieve a good intra-protocol 
fairness and to avoid starvation when competing with loss- 
based flows, such as TCP. Note that the proposed algorithm 
relies on the OWD measure, which is meaningful only in the 
case of synchronized endpoints. However, the controller can 
still operate properly in the case of unsynchronized endpoints 
if the desynchronization is relatively small with respect to the 
OWD experienced. 

The remainder of this paper is organized as follows. In 
Section [ll| we provide a description of the system model 
and the Network Utility Maximization (NUM) framework 
that is used in this paper. In Section [HI] we describe our 
new congestion control algorithm and we analyze its stability 
in Section [TV] In Section |Vj we provide some last details 
about the correct implementation of the controller and present 
the simulation results. Section m describes the related work. 


Finally conclusions are provided in Section VII 


II. Network Utility Maximization 


A. System Model 

We consider a system with a set of R users (or flows) 
indexed by r G R sharing a set of network resources. Each 
user transmits data at a sending rate x r , in a single-path unicast 
communication between two endpoints. Let l G L be the links 
of the network, and 1Z be the L x R routing matrix, where 
lZi r = 1 if link l is used by user r and zero otherwise. The 
total rate passing through link /, denoted by yi , can then be 
defined as 

Ui = ^ ^ TZi r x r . (1) 

reR 

Every link has a fixed maximum channel capacity q, which 
is constant over time. Each link is preceded by a buffer that 
accumulates the data in surplus when yi exceeds the link 
capacity q. The queueing delay at the buffer of link /, qi(t ), 
evolves over time as follows: 

m - - (:Vi ~ ci)g , ( 2 ) 

Where (z)+ is a projection that keeps the queuing delay 
positive. Here, as in the remainder of the work, we identify 
by i the derivative of the variable z with respect to time. A 
data unit, or packet, that arrives at link l at time t takes a time 
equal to qi(t ) before being actually sent over the link. We 
further denote by pi the propagation delay of link l, which is 
defined as the time required for the data to propagate through 
the physical link; we assume pi to be constant over time. 
Therefore the total time for a data unit to traverse the link 
l is given by the sum of the propagation and queueing delays, 
i.e., di = Pi + qi. The total one-way delay experienced by user 
r, e r , is given by the sum of all the delays encountered on 
the path that connects the source node and the receiver node, 
which can be mathematically defined as 

e r = ^^1Zi r di. (3) 

leL 


Finally, the network buffers have a maximum size q^ AX and 
a droptail policy is implemented. This means that when the 
queue length reaches q^ AX , the next incoming packets are 
discarded. The loss ratio for link l when its buffer is full 
corresponds to: 


7TZ = 



(4) 


and the total loss ratio for user r is: 


7IV = 1 - H Kir (! - n) , (5) 

leL 

which, if the loss ratios of the links are small, can be 
approximated by 

7I> - (6) 

leL 

We further introduce another notion of communication delays 
between the network nodes. We denote by the delay 





3 


experienced by data packets from the source node of user r 
to the inner node located at the end of the link Z. Note that 
rh is defined only if link Z is a link of the route of flow r, 
and rh = e r if Z = L r , with L r being the final link of route 
r. Introducing the timing aspects in Eq. 0 leads to have that 
the total rate of link Z at time t is a function of the sending 
rates at time t — this mean^J 


Vl(t) = ^2 Tli r x r (t - r/j). 


( 7 ) 


reR 


Similarly we define as the time needed for the data to 
travel from link Z to the sink node and then to be sent back 
to the source node r. Note that any kind of network event is 
first detected by the receiver node and then is sent back to the 
source node, therefore the following condition holds: 


RTT r = t/ ; + r b rl , VI er. 


( 8 ) 


The RTT r of user r can also be expressed as a function of the 
experienced user delay: 


RTT r = e r 


( 9 ) 


where e h r is the total experienced delay of the backward path. 
In the cases where the backward path is not congested, it is 
reasonable to assume that e h r is equal to the propagation delay 
of the forward path. In any case, we assume that the backward 
delay e h r does not depend on the rate x r . 

We introduce now the concept of utility function. We denote 
by U r (x r ) the benefit for user r of sending data at rate x r . The 
utility function is usually considered to be a concave increasing 
function of the rate. In the following we consider a logarithmic 
utility function given by: 


U r (x r ) = h log(x r ), 


( 10 ) 


where h is a simple weight parameter that can take different 
values depending on the user r, and thus modify the impor¬ 
tance of the different flows. Finally, we point out, that our 
framework can be extended to any differentiable increasing 
concave utility function, leading possibly to different results. 

B. Optimization Problem 

We now define the NUM problem based on the framework 
of 11 ]. The goal is to optimally allocate the rates of the users in 
such a way that the overall utility is maximized and that the 
capacity constraints of the network links are respected. The 
NUM problem is typically defined as follows: 


NUM: maximize U r h 

x L —rf' 


reR 


subject to 7 Zi r x r < q, l == 1,..., L. 


(ID 


leL 


The NUM problem can ideally be solved exactly in a cen¬ 
tralized way. In this case the exact solution would be first 

] Note that in case of losses Eq. <[7) and Eq. {1} do not hold exactly due to 
the actual rate decrease caused by packet drops. The equations can however 
still be considered valid in low-loss regime. 


computed and then communicated to the users. As a result 
the capacity constraints would never be violated, leading to 
no losses and no queueing delay at the bottlenecks links. The 
requirement of a prior full knowledge of the network state 
prevents this solving method to be actually usable. Thus, the 
NUM problem is typically decoupled and then solved in a 
distributed manner. 


C. Solution by Decomposition 

We discuss now the most commonly used approaches to 
solve the NUM problem, which include solutions based on 
penalty decomposition and on dual decomposition, and we 
point out their main limitations. We refer to [4| for a detailed 
tutorial on decomposition methods for NUM. A viable method 
is by using penalty functions, or prices, which map the 
violation level of the capacity constraints into a negative utility. 
The problem in ( pTj ) can be reformulated as follows: 


maximize U r (x r ) 

x ^ J 

reR 


leL 


rvi 

Jo 


9 i(z)dz 


( 12 ) 


where gi (z) is seen as the price to pay for using link l when 
the link rate is equal to z. It is important for gi(-) to be a 
positive and increasing function of the link rate. The problem 
in Eq. (12] ) can be solved by a gradient-based algorithm with 
the following the rate update equation: 


x r = a r 


U' r (x r ) - Zi r gi(yi) 

v leL / 


( 13 ) 


where U' r {x r ) is the derivative of the utility function with 
respect to x r . In the reminder of the paper the notation f'(z ) 
denotes the derivative of the function f{z ) with respect to a 
general variable z. Imposing the loss ratio of link l as price: 
gi{yi) = 7 ri(yi), and assuming lZi r 7Ti ~ 7r r , the problem is 
decoupled since users need to know only their own utility 
function and their loss ratio 7r r to compute the rate update. 
Users can easily estimate their loss ratios by observing the 
number of dropped packets at the receiving node. The main 
drawback of this solution is that at the equilibrium losses are 
always experienced, which means that bottleneck buffers are 
always full and large queuing delays might be experienced. 
A large family of congestion control algorithms, such as the 
classical loss-based version of TCP, can be modeled as systems 
governed by Eq. m 

Another possible way to solve the NUM problem is by dual 
decomposition. The optimization problem can be solved in a 
distributed way by using a primal-dual algorithm based on the 
following update equations: 


X nr- - Oinr > 


u' r (x r ) - yni r xi 

k leL / 


A i = vi ( yi - ci) + 




(14a) 

(14b) 


where A/ is the dual variable associated to the capacity 
constraint of link Z, and vi is a simple positive parameter that 
controls the rate of update of the dual variable Xj. Note that 
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if we set vi = 1/q, the dual variables have exactly the same 
form of the queueing delays defined in Eq. ([2]). Therefore, users 
can compute Eq. ( |14a| ) by estimating the total queueing delay 
of their own route, and adapt their rates accordingly. For a 
given utility function the delay experienced at the equilibrium 
of a user depends on the bottleneck capacity. Generally, the 
larger the bottleneck capacities q, the larger the user rates x r 
at equilibrium, and the lower the delays at equilibrium. It is 
worth noting that a flow that converges at the equilibrium to a 
rate equal to x, needs to experience (create) a certain amount 
of queueing delay along its route, which is usually called self- 
inflicted delay. 

The basic dual decomposition method of Eq. <d has two 
main limitations: i) it is not robust against loss-based flows, as 
already explained in the introduction; ii) it assumes a perfect 
knowledge of the total queueing delay (when \[ = q{). In 
practice, users can measure only the sum of the propagation 
and queueing delay, and extrapolate a precise measure of the 
queueing delay from the total delay is highly challenging. 

In summary loss-based congestion control algorithms ne¬ 
glect the delay aspect in their algorithms, while delay-based 
congestion control algorithms always adapt to the delay 
measure, loosing in terms of performance when competing 
with loss-based algorithms. In the next section, we describe 
our congestion control algorithm which is able to overcome 
the aforementioned limitations of classical congestion control 
schemes. 

III. Delay-Constrained Congestion Control 
Algorithm 

A. Control Algorithm 

In this section, we present our DCCC algorithm, showing 
how it overcomes the main limitations of the existing con¬ 
trollers. The rate update equation that we consider for our 
algorithm is the following: 

x r — k r x r (U'(x r ) — v r (e r ) — e r — 7r r )+ . (15) 

We now describe the different terms of Eq. ( [15] ) in detail. The 
parameter k r tunes the update speed of rate x r . The first term 
in the brackets is the derivative of the utility function [/'(•). 
The term v r (-) is the delay penalty function that maps the 
OWD into a penalty. Similarly to the loss price definition in 
Eq. 0, we write the delay penalty as: 


(16) 

where RTT r is the round trip time of user r, e r and e h r 
are the forward and backward experienced delays of user r 
respectively, /? is a scaling factor and T r is the delay threshold 
of user r. The delay threshold is related to delay that the system 
experiences at the equilibrium. The value of v r (e r ) is equal to 
zero if e r — T r < 0 and equal to f3(e r — T r )/RTT r otherwise. 
The normalization of the price by RTT r is motivated by rate 
fairness improvements and stability conditions. Note that this 
function is not a linear function of the experienced delay, e r , 
but rather a monotonically increasing function of it. 


v r (e r ) — (3 


3 r — T r 

RTTr 


= p 


(e r -T r ) 


-T r 


r / (e r -T r ) 


The derivative of the experienced delay, e r , does not modify 
the equilibrium of the system, since the time derivative at 
the equilibrium point will be zero by definition. However, 
it improves the controller performance during the transients, 
since it provides information about the variation rate of the 
feedback variable. The last term in Eq. & 7r r , takes into 
account the experienced losses, following Eq. ([5]), so that the 
algorithm is able to operate in both delay-based and loss-based 
scenarios. 

In the case of no losses (7r r = 0), our controller behaves 
as a delay-based controller. The experienced delay at the 
equilibrium is evaluated by setting the time derivatives to zero 
in Eq. ( [15] ): 

e r = ^Tu' r (x r ) + T r = RTT r A + T r . (17) 
Substituting Eq. ([9| into Eq. ( [17] ) we obtain: 


e b r h/(Px r )+T r 
1 — hj (/3x r ) 


(18) 


From Eq. <©, we observe that: i) e r converges at the 
equilibrium to larger values than T r , and approaches to T r 
for increasing values of x r \ ii) the rate at equilibrium has to 
verify the following inequality: 


x r > h//3. (19) 

This means that the delay price v r (e r ) in our DCCC algorithm 
never forces the sending rate to be lower than h//3. 

The main benefits of our penalty function can be summa¬ 
rized as follows: 

• The non-linearity of the penalty function protects the 
flows from starvation when competing against loss-based 
algorithms. Fig.[2 depicts the shape of the penalty 
function of Eq. ([16) for different values of the propaga¬ 
tion delay, when the backwards delay, e h r is considered 
to be equal to the one-way propagation delay in the 
forward direction. The value of the penalty saturates to 
/3 for large values of the experienced delay, which is 
the typical scenario that we encounter when competing 
with loss-based flows. As a consequence the experienced 
delay can never force the sending rate to decrease to a 
value lower than h//3 thus preventing starvation. 

• The non-linearity of the penalty function alleviates un¬ 
fairness problems caused by heterogenous propagation 
delays among the users. Since our control algorithm 
uses the total experienced one-way delay instead of 
the queueing delay, it may lead to unfairness when a 
bottleneck link is shared among users with different 
propagation delays. However the non-linear mapping 
of the delay helps to alleviate this problem when the 
available capacity is low. This can easily be understood 
by looking at the shape of the penalty function in Fig. [2] 
Since the penalty value tends to saturate for large delays, 
i.e., low available capacity, it means that users with 
different propagation delays will have similar penalty 
values in this scenario, and as a consequence similar 
sending rates. 
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Fig. 2. Delay penalty as a function of the experienced delay for different 
values of propagation delays, measured in units of ( 3 . 


The loss-based part of the algorithm, 7r r , works as an 
additional penalty that lowers the value of the rate at the 
equilibrium in case the delay penalty is not able to reduce it 
significantly. For instance, when congestion is experienced for 
low rates, x r < h//3, the loss ratio ir r forces the rate to further 
decrease. Losses can also happen due to the presence of loss- 
based flows in the network or to the presence of short buffers 
inside the network. In the extreme case where the maximum 
end-to-end maximum delay of a route is smaller than the delay 
threshold, i.e., e^ AX < T r , the delay penalty is always zero 
and the rate is fully driven to the equilibrium exclusively by 
the loss term 7r r . 

B. Controller Implementation 

We now briefly discuss the practical implementation of the 
DCCC described above. Our theoretical analysis relates to a 
continuous system, while in practice we work in a discrete 
context, where entities that travel through the links are data 
packets rather than continuous flows. We therefore need to 
adjust the controller in Eq. to work in a discrete domain. 

In a packet based model a measure that can practically be 
evaluated is the interarrival time of the packets at the receiver 
node. We now explain how, by using this quantity, we are able 
to build a term that incorporates both aspects of our controller, 
namely the delay-based part and the loss-based part. More 
specifically, the two terms that will be unified are the queueing 
derivative term, e r , and the term 7r r that takes into account the 
losses of the flow. We start the derivation of the unified term 
by finding the connection between the interarrival time and the 
receiving rate, then we give the expression of the merged term 
and show that it corresponds to approximate the sum of ir r 
and e r 

We first consider the case of long buffers where no losses 
can be experienced. Ideally the interarrival time is inversely 
proportional to the received rate. If we measure the receiving 
rate in packets per second, we can write: 

x recv {n ) = ——- — -— = — , (20) 

t a (n) — t a (n — 1) A t a (n) 

where t a (n ) is the instant of arrival of the n-th packet. Noting 
that t a (n ) = t s (n ) + e(n), where t s (n ) is the sending time of 


packet n, and that the time between two consecutive departures 
is equal to l/x r , we can write 


x recv (n) = _= _ 

r l/x r + e r (n + 1) — e r (n) l/x r + A e r (ri) 

( 21 ) 

where A e r (n) is the variation of the OWD between two 
consecutive packets. As the propagation delay is fixed, A e r (n) 
corresponds to the variation of the queueing delay. Since 
the variation is evaluated between the sending time of two 
consecutive packets, we can write e r (n) ~ A e r (n)x r . Recall 
that we measure the sending rate x r in packets over seconds, 
thus A e r (n)x r is dimensionless, as e r . If we substitute this 
approximation in Eq. © and solve for e r we obtain: 


e*y 


( 22 ) 


The value of x r r ecv can be calculated at the receiver using 
Eq. m while the value of the true sending rate can be reported 
in the header of the transmitted packets. 

We now analyze the meaning of the right hand side of 
Eq. ( [22] ) in the case of losses. We consider the case of droptail 
buffers, thus losses are experienced only when the buffers 
are completely full. The loss ratio for user r is defined as 
7r r = 1 — ^—, or equivalently: 



(23) 


Note that the left hand side of Eq. ( [23] ) is equal to the right 
hand side of Eq. ( [22] ). For small loss ratios, 1—7r r ~ 1, Eq. ( [23] ) 
becomes 


x r 


_ ^reci* 

X recv 


— 7 T r 


(24) 


According to Eq. ( [24] ) and Eq. ( [22] ) the term ^ Xr x Zcv —) can 
be used in both delay-based scenarios (to approximate e r ) and 
loss-based scenarios (to approximate 7r r ). The advantage of the 
merged term is that we do not need to distinguish between the 
two operation modes of our algorithm, and we simply need to 
evaluate the value of this term at every rate update step. 

We can finally write the rate update rule that governs the 
DCCC algorithm in the discrete domain as 


x n r ew =x r + T s k r x r (u'(x r ) - / 3 ^—^ 

Xr{t - RTT r ) - <3 

X recv / ^ 

where T s is the time interval at which the rate is updated, 
and x r (t — RTT r ) denotes the delayed sending rate used to 
calculate the loss and queueing derivative term (the estimation 
of the received rate and the sending rate need to correspond 
to the same set of packets for a correct calculation of this 
final term, thus communication delays cannot be neglected). 
In Section [VJ we explain in detail how to effectively set the 
different parameters of the rate update equation ( [25] ). 




















IV. Stability Analysis 
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In this section, we discuss the stability of the DCCC 
algorithm based on Eq. focusing on the case of delay- 
based regime. In order to model a network where the only 
congestion signal experienced is the OWD, we set the length of 
network buffers to be infinite. In this case, the flows experience 
no losses, (i.e., 717 = 0 V/) and reach the equilibrium point 
using only the delay measurements. We obviously assume that 
the equilibrium point exists in this case. Note that even if the 
stability of similar delay-based controllers has already been 
studied in other works 0 due to the non-linear mapping 
of the experienced delay in Eq. ( p~5] ), those proofs do not apply 
directly to our algorithm. The stability of the algorithm in loss- 
based regime is commented at the end of the section. 

We first show the global stability of the non-linear DCCC 
for an ideal scenario when the communication delays are 
negligible, i.e., ^ 0 ^ 0, for a general case of R users 

and L links. The communication delays are negligible when 
they are remarkably smaller than the timing characteristics 
of the control system. In the second part of the section, we 
focus instead on local the stability of the controller when 
communication delays are non-negligible. 

A. Negligible Delay Case 

In order to study the global stability of the undelayed system 
we extend the analysis carried out in (6) to the case of non¬ 
linear price function. 

The global stability proof is based on the passivity analysis 
of dynamic systems 0 0 A dynamic system characterized 
by an input u, state x, and output y is said to be passive if 
there exists a positive definite storage function V such that its 
derivative can be written as: 

V < —W(x) + u T y , (26) 


Users Dynamic 



Links Dynamic 


Fig. 3. Block scheme of the congestion control 


experienced delays e and their derivatives e, while its output 
corresponds to the sending rates x. Similarly, the links system 
has the link rates, y, as input variables and the links delays, 
d and d, as output variables. The routing matrix 1Z maps the 
user rates to the link rates and the link delays to the users’ 
experienced delays. Finally, the equilibrium point of the system 
is reached when the dynamic equations ([2]) and ( p~5j ) are set to 
zero. This is equivalent to having v r (e r ) = U'(x r ) and yi = ci 
if qi > 0, or yi < q if qi = 0. Since we are at equilibrium, 
qi = 0; we further have e r = ^2 ieL IZwdi = 0, where di is 
the sum of the queueing delay qi and the propagation delay pi 
(which is constant over time). 

We consider the following candidate storage functions for 
the user and link subpart respectively: 


where W (x) is a positive semi-definite function. If two passive 
systems are interconnected in a negative feedback loop, then 
the sum of their respective storage functions is a Lyapunov 
function for the interconnected system. Indeed, the output of 
one system is the opposite of the input of the other one, so 
the two terms u T y vanish: 

V < -Wi(xi) - w 2 {x 2 ) + ujyi + U2V2 (27a) 
= -Wi(a:i) - w 2 (x 2 ) - yfi/1 +y±y 2 (27b) 

= -W 1 (x 1 )-W 2 (x 2 ). (27c) 

Our dynamic system can actually be modeled as an intercon¬ 
nection of two systems (namely, the users and links dynamics 
in Fig. [3), which drive the behavior of our congestion control 
framework. By proving that these two separate systems are 
both passive, then we also prove the global stability in the 
sense of Lyapunov for the entire system. 

Let first introduce some notations that are used in our stabil¬ 
ity proof. The operator : denotes the value of the variables at 
the equilibrium point, and S denotes the deviation of a variable 
from its equilibrium point, e.g., Sx = x — x. We denote with 
Vuser and Vu n k the storage function of the users and links sub¬ 
systems respectively. The inputs of the users system are the 



Vunk = - '^Sdfci + — - yi)di, (29) 

Z l£L a leL 

for some a > 0. Note that since di> 0 the two storage func¬ 
tions are positive definite functions for Sx and Sq respectively. 
It can be verified, by taking the time derivative of the two 
storage functions, that inequality of Eq. ( |27c| ) holds for two 
valid functions W user and Wu n k, proving the stability of the 
system. The full proof can be found in Appendix [A] 

B. Non-negligible Delay Case 

We now study the local stability of the system when the 
communication between network nodes is affected by non 
negligible delays, as it is typically the case in practice. In this 
case we first linearize the rate update equations of the non¬ 
linear delayed system at the equilibrium point, then we study 
the local stability of the delayed system similarly to 0 0 
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When communication delays are non-negligible, Eq. © 
can be written as: 

x r (t) = k r x r (t) (u'(x r (t))— (30) 

VrC^Klrdlit ~ T r b ,)) - ^7 h r di(t - T b ,)) 
leL ieL Xr 

while the queueing delay given by Eq. ([2]) becomes: 



Next, solving ( [33] ) for 5x(s) we obtain: 

6q(s) = C~ 1 lZf{s)s~ 1 {Is - KXU"Y x 

KX (-V 7 - s) 7 if (s)Sq(s). (34) 

From Eq. ([34]) we can easily determine the return loop ratio 
F(s) (9), p0|, of our multivariable feedback system: 

F(s) = C- 1 n f (s)s- 1 (Is - KXU")~ x KX (V + «) Uj (.s). 

(35) 

Noting that 7?^(s) = diag(e sRTT )7 Z^(—s) and using the 
property that diagonal matrices commute, we can write: 


The new equations © and © represent the users and 
links dynamics taking into account the communication delays. 
Recall that and r h rl capture the time needed for the packets 
to go from source r to link l, and for the feedback information 
to be received by the source respectively. Recall also that the 
congestion information from link l needs to reach the end node 
of user r before being sent back to the source node. As a 
consequence, the sum T rl + T rl does not depend on l and is 
equal to the RTT of the route, i.e., + r^ = RTT r . When 

we linearize Eq. ( [30] ) and Eq. ( [3l] ) at the equilibrium point, 
we obtain the following equations: 

Sx(t) = k r x r (u r (x r )Sx(t) — v'(e r ) Hi r Sqi(t — r^)) 

ieL 

- ^KirSqtit-Tfo), 
ieL 



where U" corresponds to the second derivative of the utility 
function calculated at the equilibrium point, and v' T is the 
derivative of the penalty function calculated at the equilibrium 
point. By taking the Laplace transform of the above equation 
we obtain: 

sSx(s) = JCX (u"Sx(s) — V'Tl£(s)5q(s) — slZ^(s)Sq(s)^ 

sSq(s) = C -1 (7 Zf(s)Sx(s )), (33) 

where Sx indicates the deviation of the variable x from the 
equilibrium point, i.e., Sx = x — x, and Sx(s) refers to the 
Laplace transform of Sx. The same notation applies to Sq. The 
system of equations ( [33] ) is written in a matrix form, where C 
is an L x L square diagonal matrix whose entries are equal 
to q. The routing matrices TZf(s) and 7 Zb(s) embed the delay 

f 

information and are defined as: 7 Zf i r (s ) = e~ ST n if user r 
employs link l and 0 otherwise, and analogously 7£& i r (s) = 
e~ ST n if user r employs link l and 0 otherwise. Then, JC and X 
are R x R squared diagonal matrices which contain the values 
of the gains k r and the values of the rates at equilibrium x r 
respectively. V' and U" are R x R squared diagonal matrices 
whose entries correspond to the values at the equilibrium point 
of the first derivative of the penalty delay functions and to the 
second order derivative of the utility functions respectively. 


F(s) = C~ 1 'JZf(s)s~ 1 (Is - K.XU")- 1 

1C (v' + s) diag(e“ sRTT )XTZj(-s). (36) 

For the sake of clarity, we introduce the matrix G(s): 

G(s ) = s-'ils - K.XU ") _1 /C (v 7 + s) diag(e _sRTT ), (37) 

this is an R x R diagonal matrix. Similarly to Q, we further 
introduce the matrix 


n{s) = diag(l/V9)^ / (s)diag(V^)- (38) 


Since the eigenvalues of matrix product does not depend on 
the order of the matrices we can write: 

a(F(s)) = a ( TZ(s)G(s)iZ T (-s )) , (39) 

where cr(-) denotes the set of eigenvalues of a matrix. We 
can now verify the stability of the system using the Nyquist 
stability criterion. We set s = ju: , where j is the imaginary 
unit, and we vary its value on the Nyquist path. The trajectories 
of the eigenvalues of the system as a function of juj must not 
encircle the point — 1 + jO for the system to be stable. We use 
now the main result of GD 

a ( F (ju)) e p(H T (jio)n(-ju)) co(0 U <r(G(jw))), (40) 


where p(-) denotes to the spectral radius of a matrix and co(-) 
denotes the convex hull. Eq. ( [40] ) states that the eigenvalues of 
F(juj) are located on the convex hull made by the eigenvalues 
of G(juS) scaled by the spectral radius of 1Z T (ju)TZ(-ju). 

From p2) , we further know that the spectral radius 
p(it T (juj)lZ(-ju)) < M, with M being the maximum 
number of links used by any user r. Hence, to prove the 
stability of the system, we need to show that the eigenvalues 
of G(ju) in Eq. ( [39] ) do not encircle the point — 1/M + jO in 
the complex plane. Since G(ju ) is a diagonal matrix, as can 
be seen from Eq. ( [37]) , we need to show that all the entries 
on its diagonal verify the Nyquist stability criterion. Defining 
G r (juj) as the r element of the diagonal of matrix G(juS) we 

haVe e -j^RTT r / + • 

G r {ju) = k r — - . TT ,r (41) 

juj juj — k r x r U ” 


As the utility functions are concave, U" is negative, and so 
both poles of Eq. ( |4l] ) are non positive. With a utility function 
defined as U r (x r ) = h\og(x r ), the value of the second 
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derivative of the utility and the derivative of the price at the 
equilibrium point are respectively equal to 


u 



(3 — h/x r 

RTT r 


(42) 


where in the second equation we used the property that 
v r (e r ) = U'(x r ) at equilibrium. Note that, in order to have 
a negative zero in the transfer function G r (juj) we need the 
inequality x r > h//3 to hold. This condition supports in fact 
that h//3 is the minimum equilibrium rate for the purely delay- 
based subpart as described in Section |III| 

Finally, substituting Eq. © in Eq. (|41|), we obtain 


G r (ju) = Vr 


e -jqj R TT r &£gr +ju} 
juRTTr juj + Vrj^fT r ’ 


(43) 


where we have introduced the normalized gain r] r = k r KTT r . 
Eq. ( [43] ) is a transfer function with two poles and one zero. The 
location of the second pole and the zero are actually linked 
since they depend on the same quantities. In particular, due 
to the previous considerations about the minimum value of 
the equilibrium rate, the pole cannot be located at an angular 
frequency larger than rj r f3 /RTT r , and the zero has to be located 
between 0 and f3 / RTT r . By selecting appropriate values for the 
controller parameters h, f3 and r \ r , we can ensure that point 
— 1/M + j 0 is not encircled. The tuning of the parameters is 
complex because in general the setting of one parameter affects 
the value of the others. One possible way to proceed is to 
allocate the zero-pole couple at low frequencies and the cross 
frequency at which \G r (juj)\ = 1/M to a higher value. In this 
case at the cross frequency the zero and the pole compensate 
each other decoupling and facilitating the tuning of the rest of 
the parameters. 


C. Summary of stability analysis 

In this section we have studied the stability of our system 
in the case where the only congestion event received from 
the network is the experienced delay. The main result is that 
the non-linear mapping of the experienced delay leads to a 
stable delay-based system. The stability analysis can also be 
extended to lossy scenarios. In the case of droptail buffer 
policy, when losses are experienced the queue size is constant 
and equal to the maximum one (we do not consider the case 
of Random Early Detection (RED) policy fl3| or any other 
Advanced Queue Management (AQM) mechanism). Since a 
constant delay plays no role in the placement of eigenvalues 
of the linear dynamic system at equilibrium, the delay-based 
terms of the rate update equation disappear in the linearization 
process of the system. Hence, for the loss-based part of our 
algorithm, the linearized update equation is consistent with the 
one used in 0 © and the stability proof can be carried out 
by following the steps described in these works. 

V. Final Implementation and Simulations 

We now provide simulations results for the proposed DCCC 
algorithm. First, we explain how the controller performance is 
affected by each parameter and how to efficiently set them. 


TABLE I. 


Parameter name 

Used value 

Suggested range 

k r 

1 / (2.5RTT) 

1/(2.5T„)-1/(10T„) 

3 

0.1 

0.05-0.2 

T s 

RTT 

50-500 ms 

T r 

50-100 ms 

5-250 ms 

h 

20 kbps 

5-50 kbps 


Then we provide the simulation results where we analyze the 
basic behavior of our algorithm, the intra-protocol fairness, the 
TCP coexistence and finally we provide a comparison with 
other similar congestion control algorithms. 


A. Parameters and Simulation Setup 

The parameters of the DCCC are set by using the re sults 
obtained from the stability analysis of Subsection |IV-B[ and 
by empirical knowledge on the effect of the parameters on the 
controller behavior. 

The gain k r , the sampling period T s and the parameter (3 
of Eq. ( [25] ) strongly affect the cross frequencies of the transfer 
functions that compose the matrix G (defined in Eq. ©)• 
They therefore affect the speed and the stability of the closed 
loop system and are set to impose the stability of the system. 

Conversely, the parameters h and T r do not strongly af¬ 
fect the stability of the system. The value of h affects the 
aggressiveness of the controller, as the price at equilibrium is 
proportional to h. The price reflects both the overshoot of the 
delay threshold in delay-based environments and the fairness 
level with other loss-based protocols. The value of h reflects 
also the minimum rate that is achieved with extremely long 
buffers by the delay penalty, which is equal to h/[3. Therefore 
the value of h has to be properly tuned to find the best tradeoff 
between large guaranteed rates (i.e., large h) and not too large 
prices (i.e., small h). 

The delay threshold T r is set by the application. Ideally, if 
the two endpoints are synchronized, the application should set 
T r such that an acceptable end-to-end delay is achieved. It is 
worth noting that in order to guarantee a fully utilization of 
the channel, T r should be larger than the minimum OWD. 

In Table [I] we list for each controller parameter the value 
adopted in the conducted simulations as well as a suggested 
operation range. Finally, we point out that the parameters 
setting that we use are valid in a wide range of scenarios, 
even if they might not always lead to optimal performance. 
For example, a T r value between 50 ms and 100 ms represents 
a valid setting in a wide range of network condition, provided 
that it is tolerated by the application. For a more thorough 
discussion on the setting of the parameters, and on how 
they affect the algorithm behavior, we refer the reader to 
Appendix [B] 

To evaluate the performance of our controller, we carried out 
experiments using the NS 3 network simulator platform. We 
have tested the controller in different network topologies and 
scenarios in order to show that the algorithm is able to work in 
loss-based as well as delay-based environments. In particular, 
we consider a single link topology, Topology 1 (see Fig. [4]) and 
Topology 2 (see Fig. [9]) in our simulations. The first one is the 
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classic dumbbell topology, where several users share the same 
unique bottleneck link. The second topology is the so-called 
parking lot topology, with two bottleneck links, where two 
users employ only one of these links while a third user, with a 
longer data path, employs both congested links. All the links 
connecting the endpoints to the bottleneck are set to a high 
connection speed, e.g. 100 Mbps. We focus on low/medium 
values of the bottleneck capacity since this is the typical, 
and most critical, scenario for real-time applications, see G3 
We evaluate the performance of the DCCC algorithm under 
different metrics such as throughput, self-inflicted delay and 
fairness. We also compare the algorithm with other delay-based 
congestion controls, namely: the Network-Assisted Dynamic 
Adaptation (NADA) congestion control algorithm (TS), the 
Google congestion control (GCC) algorithm ED and the Low 
Extra Delay Background Traffic (LEDBAT) algorithm fT8| . 
For a more detailed description of the congestion control al¬ 
gorithms implementation and for further simulation test cases, 
we refer the reader to Appendix [C] and Appendix [D] 

B. Fairness Analysis 

In this set of simulations, we evaluate the performance 
of the DCCC controller when it shares the bottleneck links 
with other flows controlled by the same algorithm. Fairness is 
an important metric for congestion control algorithms; since 
it reflects the ability of flows to fairly share the available 
bandwidth without penalizing early or late starting flows. We 
consider a case with three DCCC flows that share a link with 
an unresponsive UDP flow with a constant rate of 500 kbps. 
The network topology is shown in Fig. [4] Two of the flows 
(1 and 2) start at 2 and 4 s respectively and last until the 
end of the simulation. The flow 3 starts at 100 s and stops 
transmitting at 260 s. The unresponsive UDP flow is always 
active during the simulation. The bottleneck link has a one 
way propagation delay of 25 ms, and a total capacity of 3.5 
Mbps. The threshold delay of the three DCCC flows is set to 
100 ms. 

In a first simulation we set the maximum buffer length to 
130 packets (approximately 300 ms of maximum queueing 
delay). Since T r <C 300 ms, no losses are experienced by 
the flows at equilibrium. Results are provided in Fig. [5] The 
DCCC flows fairly share the bottleneck link without penalizing 
early or late starting flows. When all three flows are active the 
delay at equilibrium is slightly higher, as expected since the 
sending rate at the equilibrium goes from 1.5 Mbps per user to 
1 Mbps per user. This behavior is indeed expected: according 
to Eq. ( [25] ) the algorithm needs a higher price, i.e., a larger 
delay, in order to reach a lower rate at equilibrium. 

We then conduct a simulation with the same settings, but 
with a maximum buffer length of 25 packets (approximately 45 
ms of maximum queueing delay). In this scenario T r is greater 
than the maximum experienced delay, therefore the DCCC 
flows are driven to equilibrium by the experienced losses rather 
than by the experienced delay. The sending rates and OWD for 
this simulation are depicted in Fig. [6] We observe that, also 
when the system is in a loss-based regime, the flows fairly 
share the available bandwidth. 



Fig. 4. Network Topology 1. 



time [s] 

Fig. 5. Sending rate and OWD for the three DCCC flows sharing a common 
bottleneck link when the equilibrium is driven by the experienced delay. 


As second scenario, we still consider the network topology 
of the previous simulations, but in this case the flows have 
different propagation delays, therefore different prices. We 
denote by \pi P 2 P 3 p±\ the propagation delays of the four 
considered flows. The capacity of the bottleneck link varies 
from 1 Mbps to 6 Mbps. The maximum queueing delay is set 
to 500 ms (the buffer size ranges from about 60 packets to 
360 packets depending on the capacity value), and T r is set to 
100 ms. We measure the average sending rate at equilibrium 
and we compute the Jain’s fairness index fT9| , which for the 



time [s] 


Fig. 6. Three flows sharing a common bottleneck, equilibrium is driven by 
losses. Drop tail bottleneck buffer. 
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Fig. 7. Jain’s fairness index of four DCCC flows with different propagation 
delays. 


Fig. 8. Minimum and maximum rates at equilibrium versus normalized 
capacity for four DCCC flows sharing a bottleneck with different propagation 
delays. 


case of N flows is defined as: 


J(x) 


(Et^n ) 2 

N ■ 


(44) 


The Jain’s Fairness index is a well known index to measure 
the fairness of rate allocation and it ranges between 1 (full 
fairness) and 1/N (poor fairness). The simulation results are 
shown in Fig. [ 7 ] where the fairness index is provided as a 
function of the normalized capacity, which corresponds to the 
total capacity normalized by the number of flows. The most 
heterogenous scenario (e.g. OWDs equal to [30 50 70 90]) is 
the least fair especially for large capacity values. However, 
when the available bandwidth is limited, which is the most 
constrained and the most critical scenario, the fairness is 
improved. This behavior is motivated by the fact that, even if 
heterogenous propagation delays lead to heterogenous prices, 
the mismatch is reduced for large prices (small capacities) 
leading to a more fair rate allocation. Fig. [8] depicts the users’ 
lowest and highest sending rate at equilibrium as a function 
of the normalized capacity. In the ideal case of full fairness, 
this plot should feature a straight line with all the rates equal 
to the normalized capacity. Even if curves in Fig. [8] deviates 
from this ideal behavior for high values of capacity, still no 
flow is experiencing starvation and a relatively good sending 
rate is achieved. For example, when the maximum propagation 
delay of one flow is three times the minimum one, the most 
penalized flow is still able to achieve a sending rate equal 
to approximately half normalized capacity. We conclude these 
results by pointing out that, unlike loss-based algorithms, for 
delay-based algorithms achieve full intra-protocol fairness in 
all possible scenarios is particularly challenging. The challenge 
is caused by the fact that flows might not commonly agree on 
the value of the price. Note that this issue is not a peculiarity 
of our algorithm for example, in other protocols p6| , (20) , 
latecomers flowg tend to underestimate the queuing delay 
and converge to larger sending rates. In our algorithm we 
are not able to guarantee optimal intra protocol fairness in 
all possible scenarios, but we mitigate unfairness issues in the 


2 A latecomer flow is a flow that starts sending data over an already 
congested (i.e., standing queueing delay grater than zero) network link. 


most constrained scenarios, sacrificing the performance in less 
constrained scenarios, i.e., when capacities are large. 

We now analyze the fairness of our controller for the parking 
lot network topology depicted in Fig. [9] Both bottleneck links 
have a channel capacity of 2.5 Mbps and a propagation delay 
of 25 ms. An unresponsive UDP flow streams through both 
links at a constant rate of 500 Kbps. For the equilibrium to be 
driven by the experienced delay, we set the threshold T r to 100 
ms for all the users, and the maximum length of the buffers 
inside the network to 100 packets (equivalent to a maximum 
queueing delay of approximately 330 ms), which ensures that 
no losses are experienced during this simulation. Flow 3 starts 
at 100 s and stops at 260 s while the other flows are active 
during the entire simulation. The simulation results are shown 
in Fig. [10| Flow 1 always gets a lower rate compared to the 
other flows. This is expected and due to the fact that its route 
is longer, hence it is penalized compared to the other flows. 

Finally, we conduct a last simulation for a mixed regime: 
the maximum queuing delay is set to 15 packets (equivalent 
to a maximum queueing delay of approximately 50 ms), while 
the threshold delay T r is set to 100 ms. Also in this case 
we observe that flow 1 achieves a lower rate than the other 
two competing flows, as shown in Fig. |TT] In this experiment 
flow 1 is experiencing losses and having a positive value of 
the delay penalty, hence we call this operation mode mixed 
regime. Note that the maximum queuing delay is set on a per 
buffer basis, thus flow 3, which passes through two congested 
links, experiences a total queuing delay of 100 ms. In this test 
case, flows 1 and 2 converge to the same rate when user 3 is not 
active because both pass through the same unique bottleneck, 
and the OWD is lower then the threshold delay for both of 
them. On the other hand, when all three flows are active, flow 
1 traverses two bottlenecks links, experiencing a double value 
of losses and converging to a lower equilibrium rate. 


C. TCP Coexistence 

We now study the performance of the DCCC when it 
competes against TCP flows. We again use a single link 
topology, with a capacity of 2.5 Mbps and a propagation 
delay of 50 ms. Three flows share simultaneously the link: an 
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Flow 1 



Fig. 9. Network Topology 2. The flow DCCC 1 passes through two 
bottlenecks links and competes with another DCCC flow on each of these 
links 



Fig. 10. Time evolution of the sending rates and delays for the parking lot 
topology when equilibrium is driven by the experienced delay. 


unresponsive UDP flow with a constant sending rate of 500 
kbps, a flow running the DCCC algorithm and a HSTCP (2l| 
flow (we provide test cases with TCP New Reno and TCP 
Westwood in Appendix |D|). The delay threshold of the DCCC 
algorithm has been set to 100 ms. 

We run simulations for different droptail buffer size ranging 
from 30 to 180 packets (corresponding roughly to 100 ms 
and 600 ms of maximum queueing respectively). The simula- 



time [s] 


Fig. 11. Time evolution of the sending rates and delays for the parking lot 
topology when equilibrium is driven by losses 



Fig. 12. Average rate at equilibrium of our algorithm and HSTCP when 
competing for a bottleneck for different drop tail buffer size. 


tion results in Fig. [12] show the average rate at equilibrium 
for the DCCC and TCP algorithms. We can see that the 
level of fairness against TCP depends on the buffer size. 
This dependency is caused by the delay-based part of the 
congestion algorithm, since the buffer size has an impact 
on the experienced delay and therefore on the rate at the 
equilibrium. In the presence of small buffers, our algorithm 
reaches a higher rate at equilibrium than TCP one. This is 
due to the fact that the loss-based part of DCCC is more 
aggressive than the TCP congestion control. On the other 
hand, in the case of large buffer size, the DCCC algorithm 
suffers against TCP. However, due to the non-linearity of the 
DCCC penalty function, the DCCC flow is protected, and it 
never starves, reaching the expected lower bound rate of h//3 
(h//3 = 200 kbps in the simulations). By modifying the value 
of h , we can tune the guaranteed rate that is reached in large 
delay environments and therefore we can limit performance 
degradation when competing with TCP. In conclusion, when 
sharing the bottleneck link with TCP, the DCCC algorithm 
cannot guarantee TCP fairness, but it still compares favorably 
with respect to other delay-based algorithms proposed in the 
literature (22)-(24), which are note able to guarantee a lower 
bound on the delay-based sending rate. 


D. Comparison with Other Congestion Control Algorithms 

We now conduct some experiments to compare our algo¬ 
rithm with other delay-based congestion controllers. We con¬ 
centrate on the behavior of the algorithms when they operate 
in delay-based mode and not on how they perform in lossy 
environments. We consider two candidate algorithms of the 
IETF RMCAT (RTP Media Congestion Avoidance Techniques) 
Working Group (25): NADA and the GCC. NADA is imple¬ 
mented according to the description of the IETF draft (26) 
(version 3) and the scientific publicatio fib) ; the GCC instead 
is implemented following the description of the IETF draft CD 
(version 2) and the detailed analysis of the scientific publica¬ 
tions (23) , (27) , (28) . However, both algorithms are moving 
targets, and the implementation follows the description found 
in the cited documents. To have a more exhaustive evaluation 
we also include the LEDBAT algorithm in the comparison 
results. For a more detailed discussion of these congestion 
control algorithms we refer the reader to Section [VI] while for 
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a detailed discussion on the implementation and parameters 
setting of these algorithms we refer the reader to Appendix [C 

We consider a single link topology. With a varying channe 
capacity and propagation delay of 25 ms. We impose a 
threshold delay of 100 ms for the DCCC algorithm and a 
target parameter of 100 ms for the LEDBAT protocol. In 
Fig. [I3j we can see a comparison of the average self-inflicted 
delay at equilibrium for NADA, GCC, LEDBAT and the 
DCCC algorithm. As ca be observed NADA, LEDBAT and 
DCCC show a different self-inflicted delay versus bottleneck 
capacity behavior. NADA is the one that shows the highest 
delay variation while LEDBAT is the most stable of the three, 
whereas DCCC shows an intermediate behavior. A large self- 
inflicted delay variation means that the flow is extremely elastic 
and can achieve a relatively high rate even when a competing 
flow makes the experienced delay increase to extremely large 
values. On the other hand, a small variation means that the 
delay at equilibrium is almost independent of the sending rate, 
but the flow might starve if another flow in the network forces 
the queuing delay to increase above this value. The type of 
behavior that is preferable depends on the type of data that 
the congestion control has to handle. LEDBAT is preferable 
for low-priority background traffic, while a behavior similar to 
NADA is preferable if the goal is to avoid starvation in the 
presence of an externally imposed high delay. 

A different discussion has to be made for what concerns the 
GCC algorithm. GCC uses OWD variations and not absolute 
OWD measurements to adapt the sending rate. Moreover, the 
GCC keeps increasing the rate until the derivative of the 
queueing delay reaches a threshold; at that point, it decreases 
the rate until the queueing derivative is smaller than a second 
negative threshold. As a result, it is impossible for GCC 
to reach an equilibrium rate: it inevitably oscillates between 
an overestimation and an underestimation of the capacity, 
therefore the experienced delay also oscillates. Even if GCC, 
tested rates, as shown in Fig. |T5J achieves a lower average self- 
inflicted delay for all the tested rates, the time variability of the 
OWD of the GCC is relatively large with respect to the other 
algorithms in the comparison, thus the maximum experienced 
delay is much higher than the average one (see Fig. [14]). In 
Fig. [14] we show a comparison of the proposed DCCC, NADA, 
LEDBAT and our simplified version of GCC when flows 
stream through a single link of 1.5 Mbps with a propagation 
delay of 25 ms. We focus on the qualitative behavior of the 
algorithms. DCCC, NADA and LEDBAT use absolute delay 
measurements and achieve a constant rate and a constant delay. 
In contrast, the simplified GCC is not able to provide a stable 
rate at equilibrium since it uses delay variations to compute the 
sending rate. Using only delay variations to coordinate users, is 
certainly a good method to mitigate latecomers’ advantage and 
endpoint synchronization requirements. However, this method 
cannot provide any information of the absolute delay value, 
which is undoubtedly a key component in users’ Quality of 
Experience. At the current state it is not clear which of the 
two types of algorithm can lead to better overall performance. 
Finally, we point out that the results shown here are not enough 
to provide an objective ranking of the algorithms. Rather, they 
are meant to reveal their main limitations and advantages. 



Fig. 13. Average OWD at equilibrium for the NADA, the simplified version 
of the GCC and the DCCC algorithms, in a single link topology. 



—Simplified Google CC 
—DCCC (threshold set to 50 ms) 
—NADA 

LEDBAT (target set to 50 ms) 

Whf 



Fig. 14. Rate and OWD evolution at equilibrium for the NADA, the simplified 
version of the GCC and the DCCC algorithms, in a single link topology. 


VI. Related Work 

Among the delay-based congestion control algorithms pro¬ 
posed in the literature, the most similar ones with our controller 
are the FAST TCP (25), the CDG (30), and the LEDBAT (18). 

The FAST TCP algorithm is a delay-based congestion con¬ 
trol based on the TCP window-based congestion control. This 
allows the FAST TCP protocol to be easily implemented but 
also prevents it to be suitable for real-time communications. 
Moreover, the algorithm adopts the RTT instead of the OWD as 
delay measure. Therefore, the controller cannot link the delay 
measure with an overall end-to-end threshold delay imposed 
by the application requirements. 

The CAIA’s delay gradient (CDG) congestion control, which 
is inspired by one of the earliest works on delay-based 
congestion control (31), uses the RTT variations to control 
the sending rate. By using relative variations of the RTT, 
the algorithm does not require neither the estimation of the 
propagation delay nor the use of any fixed threshold. However, 
only delay variations are considered by the algorithm and 
therefore there is no control on the total delay allowed by 
real-time communications. 

Finally, the LEDBAT is a quite recent delay-based con¬ 
gestion control mainly aimed for not prioritized flows. In 
particular, the controller targets to keep a constant queueing 
queueing delay at the buffer of the bottleneck link preventing 
the buffer length to increase indefinitely. In this way, other 
(possibly more important) flows sharing the same bottleneck 
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cannot go in starvation mode. However, LEDBAT suffers from 
intra-protocol unfairness and it starves when competing against 
regular TCP flows (see (22), (32) for a detailed evaluation), 
therefore it cannot be considered as viable controller for low- 
delay (but still important) communications. 

In (33) , the authors present an interesting approach to 
solve the complex problem of loss-based and delay-based 
coexistence. The work proposes a modification of the TCP 
algorithm, called Cx-TCP, with a backoff probability that is 
a linearly increasing function of the experienced queueing 
delay for small delay values, and it is null for large delay 
values. This allows the system to do not back off when delays 
are due to the coexistence with loss based flows (i.e., when 
large delay are experienced), avoiding starvation states. The 
resulting controller achieved good performance but, similarly 
to FAST TCP, being a modification of the TCP protocol, its 
properties (e.g., packet retransmissions) are not ideal for real 
time applications such as video conference applications. 

More recent solutions have been proposed in the framework 
of RMCAT: a working group of the IETF (25) which aims 
to standardize a congestion control algorithm for real-time 
media applications that is able to work in different network 
environments. Having the same final target of our proposed 
controller, the algorithms proposed in this group share similar 
objectives with our controller. One proposal is the NADA 
controller (26) , which uses the estimate of the actual prop¬ 
agation delay of the route as delay penalty and packet losses 
and an Early Congestion Notification (ECN) (34) marking 
for the loss penalty. The algorithm is able to maintain a 
consistent sending rate when competing against TCP flows 
and it maintains low end-to-end delays for medium- high- 
bottleneck link capacities. However, the controller suffers from 
large self-inflicted delays for low bottleneck link capacities. 
It is worth noting however that NADA is still ongoing work 
and according to the last version of the IETF draft the update 
rate equation has remarkably changed from the work (16) . In 
particular, the self-inflicted delay of the control algorithm in 
low capacity environments has been significantly reduced with 
the new design. 

Another proposal in the RMCAT working group is the GCC 
algorithm [17]. This controller is mainly composed of two sub¬ 
parts: the loss-based part is strongly based on the TFRC (35) 
throughput equation, while the second subpart consists of a 
delay-based congestion control algorithm. The delay-based 
algorithm in this case is substantially different from the other 
proposals. The GCC uses the queuing delay derivative, rather 
than its absolute value, to tune the sending rate. Since it is 
not required to estimate the absolute propagation delay the 
advantage of this method is that the endpoints do not have to 
be synchronized. The main issues of this delay-based algorithm 
is however the poor intra-protocol fairness (23) , (27) . For what 
concerns the loss-based subpart, it has been shown in (27) that 
the original version of the GCC suffers from starvation when 
competing against TCP flows, However in (28) , the authors 
have proposed a modification of the delay-based algorithm that 
permits to alleviate this problem. 

Finally, DFFOW (24) is another loss- and delay-based con¬ 
gestion control proposed in the RMCAT group. The loss-based 


subpart of the algorithm basically corresponds to the TFRC 
rate equation, while the delay-based term shares some similar¬ 
ities with the FEDBAT algorithm. According to the authors, 
DFFOW provides only limited throughput when competing 
against loss-based flows, such as TCP. Another more recent 
proposal in the RMCAT group is SCREAM which stands for 
self-clocked rate adaptation for multimedia (36) . This solution 
uses a hybrid loss- and delay-based congestion control aimed 
at working in wireless FTE scenarios. The algorithm conforms 
to the packet conservation principle since it sets an upper limit 
on the amount of data that is allowed in the network, similarly 
to how window based algorithms such as TCP work. However, 
according to some publicly available results (37) , SCREAM 
achieves a low throughput when competing against TCP flows 
in the scenario of long buffers. 

In summary, several hybrid loss- and delay-based congestion 
control algorithms have been proposed for real-time commu¬ 
nication. While all nicely performing in terms of experienced 
delay, loss-based coexistence and delay estimation are the two 
main open challenges. Our proposed controller alleviates both 
of them achieving i) improved performance when sharing the 
network resources with loss-based flows; ii) preserving intra¬ 
protocol fairness in critical scenarios. 

VII. Conclusion 

In this work, we have developed and analyzed a novel 
hybrid delay- and loss-based congestion control algorithm, 
namely the DCCC algorithm. The proposed algorithm is able 
to i) maintain a bounded delay communication if the network 
conditions allows it; ii) prevent starvation when competing 
against loss-based flows. Introducing a price measure based 
on the interarrival time of the packets, we are able to provide 
a controller that automatically behaves as delay-based and 
loss-based protocol, based on the actual event that triggers 
the congestion. Moreover, because of the non-linear mapping 
between the experienced delay and the delay-based congestion 
signal, the DCCC algorithm avoids starvation when compet¬ 
ing against loss-based flows. The non-linearity mapping also 
mitigates unfairness problems when the data paths of the 
users have different propagation delays. Finally, by using the 
total experienced delay instead of the actual queueing delay, 
we avoid estimation problems and unfairness issues due to 
latecomer flows. The ability to achieve a bounded delay at 
the equilibrium and the flexibility of being able to not starve 
against loss-based flows makes the DCCC algorithm a suitable 
congestion control algorithm to be used for delay sensitive 
network applications, e.g. video conferencing. As further work, 
we propose to improve TCP fairness of the DCCC algorithm 
and the speed of convergence to the equilibrium point. 

Appendix A 

Non-linear Stability Proof 

We start by analyzing the users subpart of the system. The 
time derivative of the storage function in Eq. (28]) is given in 
Eq. (45a) . It leads to V user < —W user {x) — l/aSy 1 Sd—Sy T 5d 
which has the form of a passive function similar to Eq. (26) . 
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6x t (U'(x) - v{e) - e)+ 

(45a) 

Sx T (U'(x) — vie)) — —5x T e — —Sx T (vie) — vie)) 
a a 

(45b) 

Sx T ( U'(x ) — U'(x )) — — Sx T e — —Sx T (v(e) — v(e)) 
a a 

(45c) 

Sx T (U\x) - U\x)) - -Sx T e - Sx T Se 
a 

(45 d) 

Sx T (U\x) - U\x)) +{--5y T d) + ( -Sy T )Sd 

(45e) 


- W user (x ) 


T he re sult in Eq. ( |45e| ) comes from a first inequality in 
Eq. ( |45b| ), which holds due to the projection onto the positive 
orthant of Eq. m and from the second inequality in Eq. 
( |45d| ), which holds if: 


a 

This last inequality in Eq. ( |46| ) is true if the price function is 
chosen to be non decreasing with a maximum derivative equal 
to a , which is verified for our price function in Eq. ©• It 
remains to show that W user (x ) is a positive definite function, 
which is needed to use the passivity theorem and eventually 
prove the stability of the system. The first term in W user (x) 
is: — Sx T (U'(x) — U'(x)), which is always positive due to the 
concavity of the utility function. 

For the second subpart of the system, namely the dynamics 
of the links, we now prove that it is also a passive system. We 
can easily calculate the time derivative of the storage function 
defined in Eq. ( [29] ): 

Vunk = 5q T (y - c)+ + -(c - y) T q (47a) 

y a 

< 5q T (y - c + y - y) + - (c - y) T q (47b) 

a 

= Sq T (y-c) + 5q T 5y+-(c-y) T q (47c) 

a 

< Sq T (y — c ) +5d T 5y + — Sy T d. (47d) 

^^' a 

~W link (q) 

Wher e we used the fact that Sq = Sd and q = d. Inequality 
( |47b| ) is true due to the projection onto the positive orthant, 
while inequality ( |47d| ) holds if Sy T q > (c — y) T q, this can 
easily be proved in the following way: 

Sy T q - (c - y) T q = (y - y) T Sq - (c - y) T Sq (48a) 
= (y~ c) T Sq (48b) 

= {y- c) T {y - c)+ > 0. (48c) 

The two right most terms in Eq. ( |47d| ) simplify with the two 
terms in ( |45e| ) when the two storage function are summed 
together. The missing part is to show that Wu n k is positive 
semidefinite, which means ( q — q) T (y — c) < 0. In order to 
prove this consider the following deductions. If the link at 


TABLE II. Sensitivity to parameters 


Parameter — 





Performance 
affected i 

h 

T r 

P 

kr 

stability sensitivity 

low(4) 

extremely low (40 

high 4) 

high 4) 

convergence speed 

medium(t) 

medium-high (-t) 

low(t) 

ugh(t) 

threshold 
overshoot 
at equilibrium 

ugh(t) 

medium (f) 

high 4) 

null 

value of delay at 
equilibrium 

medium(t) 

high(t) 

medium (4.) 

null 

minimum 
delay-based 
sending rate 

ugh(t) 

null 

high(j.) 

null 

loss-based 
equilibrium 
sending rate 
(small buffers) 

ugh(t) 

null 

null 

- 


the equilibrium is fully utilized, the value of the difference 
yi — ci is zero; otherwise it must be negative. At equilibrium a 
link rate cannot be greater than the link capacity, otherwise 
it would mean that the queue is growing contradicting the 
hypothesis of equilibrium. Alternatively, if the link is partially 
utilized the difference qi — qi is necessarily non negative, 
since qi = 0; otherwise it can be either positive or negative. 
Combining these two deductions, we observe that the product 
of Sq T (y—c ) is always non positive. Finally, the global stability 
of the undelayed control system for the case of no losses is 
guaranteed, as the system is the combination of two passive 
systems [71, and the sum of the two storage functions is a 
Lyapunov function for the entire dynamic system. 

Appendix B 
Parameters Setting 

In this section, we provide guidelines for setting the param¬ 
eters used in the DCCC algorithm. For the sake of clarity, in 
Table [II] we further list the effects of each parameter on the 
system performance. 

The parameters that strongly affect the stability of the 
algorithm and the time to convergence are /3 , k r and T s . To 
guarantee the stability, (3 and k r are fixed according to the 
conducted stability analysis (Subsection |IV-B| ). Since the value 
of M cannot be known in a realistic scenario we consider its 
value to be equal to 1. In our implementation, we set first 
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T s = RTT , then we set the gain k r in order to have a 
cross frequency smaller than 1/T S and avoid aliasing effects. 
Finally, we tune /? such that the zero and the pole of Eq. m 
are located at frequencies smaller than the cross frequency. 
This guarantees that the contribution of the zero-pole pair 
(in terms of magnitude gain and phase delay) cancels out 
at the cross frequency, simplifying the allocation of this last 
quantity. Finally, we set the cross frequency to a value that 
is sufficiently low to ensure the stability of the system, but 
still large enough to reduce the time to convergence. Having 
a value of k r = 1/(2.5 RTT) and a value of /3 equal to 0.1 
provides a good tradeoff between stability and speed. Note that 
the value of T r affects the speed of convergence because T r 
affects the RTT which ultimately affects the gain k r . Having 
a low threshold delay tends to make the controller faster. 

The value of ft affects the aggressiveness of the controller 
since the value of the price at the equilibrium, e.g., the 
overshoot of the delay threshold in a delay-based scenario, is 
proportional to ft. The value of h affects also the minimum 
rate that is achieved in the case of extremely large delay 
penalties. This minimum delay-based rate is equal to h//3, 
and ideally, a larger rate is better. The tuning of the parameter 
h represents the following tradeoff: increasing ft leads to a 
larger guaranteed rate for the delay-based part, but also to 
larger delays at equilibrium when operating in delay mode and 
outclassing the TCP in the presence of short buffers. Finally 
the parameter h can also be used to assign different levels of 
importance to the different flows, in this case we denote with 
ft r the value of the parameter for user r. DCCC flows with 
the same delay threshold and the same propagation delay, will 
achieve different rates at equilibrium depending on the value 
of ft r : the higher the value of ft r the higher the sending rate. 
In our implementation we set h r = ft Vr since we are not 
interested in prioritizing flows. We set ft, = 20 kbps since it 
offers a fair balance of the aforementioned tradeoff. 

The value of T r mainly affects the delay at equilibrium 
(the threshold delay affects also the delay overshoot and the 
convergence speed, however these are rather side effects that 
appear because T r affects the RTT at equilibrium). As a 
result, the main aspect that has to be taken into account when 
setting T r is the OWD at equilibrium. In general, by properly 
tuning T r , the application can achieve larger rates, at the 
price of higher delays. This is actually the tradeoff faced by 
realtime applications: higher delay and likely higher rate or 
lower delay and likely lower rate. Since T r does not affect 
strongly the stability, it can be set freely to achieve the right 
tradeoff between achieved rate and experienced delay. It is 
worth noting that i) to measure the right OWD, two endpoints 
need to be synchronized; ii) to fully utilize the channel, the 
minimum OWD needs to be larger then T r . We can then list 
the different scenarios to provide a complete solution to choose 
the threshold delay: 

1) Nodes are synchronized, the minimum OWD is approx¬ 
imately known (or upper bounded): Set T r to a value 
that provides a good quality of service to the final user. 
If this value is smaller than the estimated minimum 
OWD, T r can be set equal to the approximate minimum 
OWD. Note that in the latter case there is no way to 


provide a good quality of service to the user. 

2) Nodes are synchronized, the minimum OWD is not 
known: Either set T r to a value that provides a good 
quality of service to the final user, and possibly does not 
lead to utilizing the channel efficiently or set T r to the 
minimum observed OWD, assuring that the channel is 
used completely but possibly at the price of latecomers’ 
advantage issues, that are common to many other delay- 
based algorithms. 

3) Nodes are not synchronized. In this case, since there is 
no way to have a meaningful measure of the OWD, the 
only feasible choice is to set T r to the minimum OWD 
observed. 

In practice, the Network Time Protocol (NTP) can be used to 
synchronize the endpoints. If nodes are not synchronized, the 
effect of desynchronization affects the algorithm performance 
in a gradual manner. More precisely, when the endpoints are 
desynchronized by an amount of time AT sync , the effect on 
the congestion control algorithm is the same of adding the 
value AT sync to the delay threshold T r . Thus, the effect of the 
desynchronization stays negligible as long as AT sync <C T r . 

In this section we have analyzed in depth the different 
effects that the parameters have on the algorithm performance, 
providing general guidelines on how they should be set. 

Appendix C 

Practical Implementation 

In this section we first describe more in detail the imple¬ 
mentation of the DCCC algorithm, as well as the one of the 
algorithms used for the comparison. 

A. DCCC Implementation 

We implement our congestion control algorithm on top of 
the UDP protocol, the size of the packets is set to 1 KB of data 
plus the size required by the protocol headers, DCCC (40 B) 
and UDP-IP (30 B), thus the total size is 1094 B. We provide 
here a brief list of steps which describe how the controller can 
be implemented: 

On media packet sending 

Add to the packet header: the current timestamp, the 
current sending rate and the current RTT. 

On media packet received 

Get and store: the current OWD, the interarrival time 
with respect to the previous packet, the sending rate 
and the RTT reported in the media header. 

On feedback packet sending 

Average the OWD, the interarrival time of the 
packets and the sending rate, for the packets re¬ 
ceived since the last feedback sending event. Send 
this information to the sender adding the current 
timestamp. Schedule the next feedback sending in 
one RTT. 

On feedback packet received 

Get the information reported in the feedback packet: 
the current OWD (e r ), the received sending rate 
(x r (t — RTT r )), the average interarrival time (A t a ). 
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Then compute the RTT based on the OWD and the 
backwards OWD from the feedback packet, compute 
Eq. ( [25] ) and update the sending rate. 

It is worth noting that there is no unique way to implement 
the algorithm. The computation of the received rate can be 
done entirely at the receiver side, or alternatively all the 
operations can be left at the sender side by using a per 
packet feedback. Finally, in our implementation the timestamps 
have an accuracy of 1 ms. Since time accuracy is limited in 
real systems, it might be challenging to achieve a sufficient 
precision for the interarrival time measurement at high sending 
rates. Though we do not tackle this specific scenario but rather 
typical real-time applications that do not send data at extremely 
high speeds, executing the rate update on a fixed T$ basis 
and not on a per packet basis improves the resilience of our 
algorithm to timestamp accuracy issues. In fact at high rates 
we can average the interarrival time over a large number of 
packets, increasing ultimately the measurement accuracy. In 
our implementation for example, the interarrival time of the 
packets is averaged in one RTT window (Ts = RTT), thus we 
simply need to count the number of packets received in one 
RTT window in order to estimate the interarrival time. 


B. Comparison Algorithms Implementation 

We briefly describe here the NADA, GCC and LEDBAT 
algorithms implementations. 

The NADA algorithms implementation follows the descrip¬ 
tion of the IETF draft [26] (version 3) and of the conference 
paper 09. with the exception of the shaping buffer part, which 
is not needed since we assume an ideal data generator. All the 
parameters are set accordingly to the description present in the 
simulation section of the conference paper. In particular the 
value of the reference delay x re f is set equal to the minimum 
OWD observed during one simulation episode. We then set 
Rmax = 6 Mbps and Rmin = 0.1 Mbps; the smoothing 
parameter corresponds to a = 0 . 001 ; and the prediction 
parameter is set to =0.1. 

In the GCC IETF draft, the algorithm description is bounded 
to a realistic video encoding system, while our simulations 
assume an ideal data generator. We thus built a simplified 
Google congestion controller that uses an ideal data generator, 
following the description of the IETF draft G3 (version 2) 
and the publications (23), (27) . This permits to avoid issues 
such as data bursts or rate mismatch, possibly caused by 
the use of real live encoders, which may lead to an unfair 
comparison among controllers. The mathematical model of 
our simplified version of the Google algorithm is however 
the same of the original controller version, with some minor 
modifications involving the delay filtering. The original draft 
uses a Kalman filter to estimate the queuing delay variation 
from a set of packets that are sent simultaneously. In our 
implementation, the packets are not sent in bursts and the delay 
measurement made on a single packet is sufficiently accurate 
to be used as a reliable measurement. Finally, we kept the 
threshold parameter 7 fixed. The adaptation of this parameter 
seems to be extremely important to improve TCP coexistence 


(28) . However, in our comparison we focus only on the self- 
inflected delay with no loss-based cross traffic, so that a fixed 
parameter does not compromise the comparison (the parameter 
adaptation has been introduced in the version 2 of the draft as 
suggested in (28) ). The parameters are set according to the 
Google draft [[17] (version 2) and the descriptions found in 
(23) , (27) , (28). We set then 77 = 1.2, a = 0.9, 7 = 0.4 ms 
and the REMB sending interval is set to 1 s. 

The LEDBAT is implemented as described in the IETF doc¬ 
ument [ 18]. In particular the value of the Maximum Segment 
Size (MSS) is equal to the size of the packets, which is 1094 
B, the gain parameter is set to 0.5, the allowed increase is 
set to one MSS, the minimum congestion window to 2 MSS. 
Finally, the target parameter is set within the range 50-100 
ms (actual value specified in the different simulations) ms 
consistently with the guidelines of the LEDBAT and aligned 
with the settings of the DCCC threshold. 

Finally, note that the total size of the packets for the three 
algorithms is equal to 1094 B, while the size of the packets 
for the UDP streams used in the different simulations is equal 
to 1054 B. 

Appendix D 

Supplementary Simulation Results 

A. Bandwidth Variations 

As first scenario, we simulate a single link topology with 
an available bandwidth varying over time. To simulate this 
dynamic scenario, we consider an unresponsive (i.e., constant 
bitrate) UDP flow sharing the bottleneck link with the DCCC 
flow. While the total capacity of the bottleneck link is fixed 
to 2.5 Mbps, the rate of the UDP flow varies between 500 
kbps to 2 Mbps. Buffers implement a droptail policy with a 
maximum buffer length of 100 packets, which corresponds to 
a maximum queueing delay of 330 ms. We run three different 
simulations with different propagation delays of the bottleneck 
link, namely 25, 50 and 100 ms, and different delay thresholds, 
namely 50, 100 and 150 ms. In Fig. [15] we provide the results 
for this scenario. Simulation results show that the DCCC 
algorithm always fully utilizes the available bandwidth left 
by the UDP flow. As expected the algorithm converges at a 
delay that overshoots the imposed delay threshold of an offset 
inversely proportional to the equilibrium rate: the lower the 
rate the larger the expected delay at equilibrium. 

B. Noisy Delay Measurement 

We now analyze the performance of the proposed algorithm 
in the case of noisy delay measurements. In this scenario, three 
flows share a common bottleneck of 3 Mbps with a maximum 
queuing delay of 300 ms and a minimum propagation delay of 
25 ms. Flows 1 and 2 start at the beginning of the simulation, 
whereas flow 3 starts after 260 s. All the flows have a threshold 
delay of 100 ms. In order to introduce the noise to the 
delay measurements, every packet is delayed by a uniformly 
distributed random period in the range of [0, 50] ms^] Results 
are shown in Fig. [16] We can see that the proposed algorithm is 

3 The random delay is increased in case it would lead to packet disordering. 
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time [s] 



Fig. 15. Evolution of the sending rate over a stair-case available bandwidth. 



Fig. 17. Sending rate and OWD for the three DCCC flows sharing a common 
bottleneck link when the equilibrium is driven by the experienced delay, with 
noisy delay measurements and smoothed receiving rate estimation. 



max one way delay [s] 


Fig. 16. Sending rate and OWD for the three DCCC flows sharing a common 
bottleneck link when the equilibrium is driven by the experienced delay, with 
noisy delay measurements. 


Fig. 18. Average rate at equilibrium of our algorithm and TCP New Reno 
when competing for a bottleneck for different drop tail buffer size. 


able to correctly operate in noisy delay scenarios even without 
modifications. To reduce the noise that affects the sending 
rates, we further apply a smoothing operation to the receiving 
rate estimation as follows 

x r r ecv = + (1 - a)x r r ecv . (49) 

Fig. [IT] provides the results of the proposed algorithm with 
the addition of the smoothing operation of Eq. ( [49] ) with a = 
0.5. Simulations results show a good improvement in the rate 
stability and prove the robustness of the proposed algorithm 
to noisy delay measurements. 


C. TCP Coexistence 

We conduct here the same type of experiments of Subsection 
but with different TCP flavors, namely TCP New Reno 
and TCP Westwood. The settings of the simul ation s are exactly 
the same of those described in Subsection |V-C| In Fig. [lS] 
and [19] are shown the results for the TCP New Reno and 
TCP Westwood respectively. As can be seen, though the 
aggressiveness of the TCP flows slightly changes, in all cases 
our algorithm avoids starvation by sending data at a rate equal 
to h//3, which in this case corresponds to 200 kbps, when 
buffers are excessively long. 
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